Historically, software applications (applications) are shipped with a predefined set of tools. For example, in Corel (TM) Photopaint (TM) There is a brush tool, an eraser tool a mask tool, etc. With the increase in the use and capability of the Internet, application models have changed. Rather than shipping an application with a fixed set of tools, users can now download new tools (or components) which attach themselves to die application to augment its feature set.
This flexibility means that multiple configurations of the application can be shipped with different tool components to meet varying sales markets. It also means that users can buy an inexpensive version of the product with few tool components and then grow their tool set by selectively buying the ones for their particular needs. Trial tool components are also possible for uses to demo but will time-out after a set time if the user does not decide to purchase it.
Each component can bring with it a whole set of user interface (UI) items, toolbars, menus, dockers and shortcut keys that the application user interface framework must be able to recognize and seamlessly integrate into its current layout when the component is loaded. On top of this, any particular application user interface, or workspace can be shared with fellow users and this sharing must account for the possibility that a particular component may not be registered on the new user system.
Currently there are a number of architectures by different vendors that support components which add their own user interface items to the application. None of these, however, provide a complete, customizable UI component system that is managed at the application framework level. These known architectures require each component to manage the portions they add themselves.
Problems associated with the current art may be divided into two groups, i) the component UI is treated differently than the application UI; and ii) component UI problem when loading or unloading components, and missing components. The following are a number of component UI problems that exist with the current architectures:
i) Component UI is treated differently than application UI:                1) Some architectures only allow components to add toolbar buttons or menu items and do not allow more complex UI elements like combo boxes, edit controls, sliders, shortcut keys, shortcut key tables, toolbars, menus, dockers, etc. This is a problem since it limits the component to what it can add to the application. Many components need to have more complicated user interface controls other than buttons. For example, a bitmap transparency component could use a slider control on a toolbar to allow the user to adjust the transparency value.        2) Some architectures do not allow the user to customize all of the individual component UI elements such as an item location, caption text, tooltip text bitmap, item size, shortcut key, toolbars, menus, dockers, etc. This is a problem since not only does it limit the user from fully customizing the user interface it limits other third party developers from creating custom solutions for clients.        3) Some architectures treat component UI with a different status than the regular application UI by not allowing the component UI to add itself anywhere into the application UI. The component UI is restricted to one location in a menu or toolbar. This is a problem since it fragments the UI rather than merging it seamlessly together.        
ii) Component UI problems when loading or unloading components, and missing components:                4) Some architectures can only add or remove component UI by shutting down the application and restoring. This is a real inconvenience to the user and gives the application an unprofessional impression to the user.        5) Some architectures allow components to add their UI but do not remove the UI when the component is unloaded. Instead the UI remains visible for the user to select and then brings up a dialog box saying that this feature is not available. If the UI is to be removed it is left up to the individual component to do so. Leaving UI from unloaded components gives the application a cluttered and unprofessional impression to the user.        6) Some architectures can remove the component UI items when the component is removed but do not remove any that were customized by the user. For example, if the user copied a component button to a different toolbar, the copied button will not be removed when the component is unloaded. If the user selects it, the feature is not available. These architectures leave it up to the component to specifically search for these customizations and remove them. This too leaves the application cluttered and gives it an unprofessional impression to the user.        7) Architectures that rely on the unloading components to remove all of their UI and any user customizations also rely on the components to restore those customization if they are later reloaded. Leaving this up to each of the components puts a great burden on them and they are not all likely to do it right. If any of them do not do it properly it will confuse the user due to the inconsistent behaviour between various components.        8) Some architectures allow users to shame their UI with fellow users. If the UI happens to contain UI elements from a component that the new user does not have loaded, the UI does not disappear but is visible for The user to select. Again, this is a problem since the UI is visible but the feature is not available. This gives the application an unprofessional impression to the user.        
The following is a list of current component architectures as well as a note to where each one fails to solve the component UI problems:                1) Bitmap plugins do not solve problems 1, 2, 3, and 4 listed above.        2) Addins do not solve problems 1, 2, and 4 listed above.        3) VBA Object Models do not solve problems 5, 6, 7, and 8 listed above.        4) WordPerfect (TM) 3rd Party Handlers do not solve problems 1, 6, and 8 listed above.        
There is a need for an architecture that solves the above listed problems.